docs(pm-dispatch): 过滤/谓词语义裁决派发必须枚举编译面清单并逐面申报 (#6410) - #6464

Fixes #6410

#5930 裁决的流程半边。纯 SKILL 文本改动,不碰任何编译器 / 求值器代码。

0. 前置:串行链头 #5925 的分支核实(分诊 17:55Z 点名)

分诊列出四张卡同落 .claude/skills/pm-dispatch/SKILL.md,并指 #5925(pm:dispatched、assignee 非本座位)为链头。动笔前核实:

git ls-remote --heads origin | grep -c '5925'   →  0

结论:origin 上不存在 #5925 的分支。 首次 grep 曾出现一条疑似命中,复核后是 SHA 里的 5925 子串(fa68ce39ba55925d6… refs/heads/claude/peaceful-allen-aZ1ir),不是分支名 —— 这正是「照抄第一眼结果」会出错的一处,故记录在此。

补充核实:全部远端分支名里没有任何 issue-5925 / sediment 形状的分支;当前仓库仅 2 个 open PR(#6208 changeset-release、#6461 spec 锚点),都不触及本文件。

⇒ 与 #5925 的落点不相交(它没有在飞编辑),正常推进。⛔ 未改其状态、未认领、未催。

1. 条款落点(before / after)

落在 step 5 派发提示词指引区,紧接「拒收类用例的最低断言集」条款之后、「Issue 正文是线索」之前 —— 与该区已有的两条「派发令的标准条款」同构(同样的 适用判据 → 原话 blockquote → 理由 骨架)。

before(origin/main): step 5 只有一条相邻条款「多面组件:测试落点是共享一致性覆盖」(1342–1362 行)。它管的是测试往哪放,不管清单与申报。

after: 新增常设条款,含 (a) 派发令必须枚举完整编译面清单,(b) PR 必须逐面申报「已改 / 本就合规(给证据)/ 明确不在范围(给理由)」,(c) 清单由 PR 维护(与域表同一纪律),(d) 派发前必须复核再抄。

关键一句(原话,进派发令):

本单改的这条语义由多个互相独立的编译器 / 求值器各自实现。派发令列出的每一面都必须在你的 PR 正文里有一个结论:已改 / 本就合规(给出证据)/ 明确不在范围(给出理由)。⛔ 不许静默略过 —— 评审把「没提到的面」一律读作「漏掉的面」,不读作「不需要改」。

文本形状参照 #5298 §1(已读原文):该节把每个实现面逐行列进一张表、每格是实测结论而非叙述。本条款的清单沿用这个形状。

2. 逐面只读核实(⛔ 未照抄卡片,全部实测 @ main 48f98b0)

与卡片的差异(以实测为准,已反映进 SKILL 清单):

1. 三处包路径已搬家 —— 驱动进 packages/drivers/、服务进 packages/services/,filter-normalizer 还在 strategies/ 子目录。卡片给的是裸文件名,照抄进派发令会指向不存在的路径。已把完整路径 + 行号写进清单,并在条款里加了一句「⛔ 不要凭这张表的记忆填派发令 + 复核 grep 串」。
2. 多出一次历史复发 —— 卡片举了两例($not 的语义在 driver-sql 与 driver-memory / formula 之间分叉：NULL 行的去留相反，$not: {} 一个是 TRUE 一个是 FALSE #5146→drivers(turso): remote 模式没有继承 #5146 的 $not NULL-safe —— 同一个 TursoDriver,local 返回 NULL 行、remote 不返回(实测,origin/main) #5903、fix(service-analytics): read scope 的 { $not: {} } 不再整表放行,$not 改为 NULL-safe (#5297) #5326/fix(service-analytics)!: 作者的 where 也 NULL-safe —— $not 下推守卫、{$not:{}} 为零行、{} 析取项吸收 $or (#5325) #5335),实测代码注释里有第三例且最新:objectql/src/having-filter.ts:37 原话是 HAVING 面「was not in that PR's inventory, which left this file as the lone holdout」(非否定路径上的 $ne / $nin / $notContains:driver-sql 排除 NULL 行,driver-memory / formula 返回它们(#5146 只裁定了 $not) #5298 的裁决由 PR fix(drivers,analytics,formula): $ne / $nin / $notContains 在 $not 之外也 NULL-safe (#5298) #5962 落地时漏掉)。这一例的判别力最强 —— 那次派发确实有一份 inventory,只是不完整,而没有任何机制要求它完整,正是本条款要补的位置。已写进条款理由。
3. 半面的措辞 —— 卡片称 having-filter 为「半面」,而代码注释称它是 "the FIFTH evaluation face"(两者计数基准不同)。清单保留「半面」标注但写明申报义务不打折,并记下它是唯一没有 conformance 表覆盖的面(FILTER_LOGIC_CASES 不驱动 HAVING 路径)⇒ 漏了它连门禁都不会红。

3. 反向验证(先申报,后执行)

⚠️ 纯文本纪律改动,无可执行运行时 ⇒ 模板式「改前红 / 改后绿」不适用,未硬套伪造一个红。改为下面三条申报。每条标明实测还是论证。

声明 A — 条款可判定(本单唯一有判别力的验证)

申报: 把三个真实历史漏面案例代入,比较旧文本与新条款各给出什么判断。

A-1(实测):旧文本给不出「逐面申报」这个判断。 在 origin/main 的内部 SKILL 上逐 token 计数:

origin/main 上 实现面 仅 3 处命中(1343 / 1346 / 1361),全部属于「多面组件:测试落点」那条测试放置条款 —— 它要求的是「新用例进共享一致性覆盖」,不是「清单」也不是「申报」。

⚠️ 一处容易误读的命中,如实记录:origin/main 上 申报 有 7 处命中(464 / 500 / 503 / 743 / 751–753 / 1698 / 2215),但读上下文全部是 PM 跨座位的「文件面申报」防撞协议(申报本单碰哪些文件,避免两个 PM 撞车),与「一条语义的哪几个实现面各自什么结论」是两个概念。⇒ 旧文本确实零覆盖。

A-2(论证,非实测):新条款对三例的判断。 历史不可重跑,以下是把条款文本代入的推演:

A-3(实测):证据出处不是我的转述。 三例的成因都写在代码注释里,已逐条读原文:

• driver-turso/src/remote-transport.ts:1731 — "LOCAL mode inherits that fix (TursoDriver extends SqlDriver), this independent compiler inherited none of it"
• spec/src/data/filter.zod.ts:370 — "read-scope-sql was aligned by fix(service-analytics): read scope 的 { $not: {} } 不再整表放行,$not 改为 NULL-safe (#5297) #5326 (closing read-scope-sql 的 $not 有两处与 SQL 驱动分叉:非 NULL-safe(#5146 后的最后一个异类),且 { $not: {} } 编译成空 → RLS 整表放行 #5297) and the analytics filter-normalizer by fix(service-analytics)!: 作者的 where 也 NULL-safe —— $not 下推守卫、{$not:{}} 为零行、{} 析取项吸收 $or (#5325) #5335 (closing service-analytics 的第二个 SQL 编译器 filter-normalizer.buildNode 仍带着 #5297 的三条分叉:$not 非 NULL-safe、{$not:{}} 不加 WHERE、$or 的 {} 析取项被丢 #5325)"
• objectql/src/having-filter.ts:37 — "was not in that PR's inventory, which left this file as the lone holdout"

A 结论: 判别力成立。A-1 / A-3 为实测,A-2 为论证 —— 不把 A-2 写成实测。

声明 B — 清单与实测一致

申报: 逐面 grep,证据表见上文第 2 节,含 3 处与卡片不符之处。结果:实测通过,SKILL 里的清单反映的是实测现状(完整路径 + 行号)而非卡片原文。

声明 C — 三轴框架逐字节相同

见下节。结果:实测通过。

4. 三轴决策框架:diff / cmp / md5 三重取证

⚠️ 直接按行号截取会被本 PR 的插入整体位移,故用内容锚点提取 4 份拷贝(锚点镜像 scripts/check-skill-frame-sync.mjs 的 COPIES 表)后再比对。

4/4 逐字节相同。 位移量与两处插入的行数(内部 +49、发布件 +37)精确吻合,即位移全部来自本 PR 的新增段落,frame 段本身未被触碰。.claude/agents/os-dev.md 完全未改。

⚠️ check:skill-frame-freshness 末行读作 1/3 framework files are byte-identical,这不是 frame 漂移。 该计数按整份文件计而非 frame 段,本 PR 同时改了 3 份 frame-bearing 文件中的 2 份 ⇒ 必然显示 1/3,gate 仍 EXIT=0。#6460 已实测并在其 PR 正文澄清过同一现象。

5. 发布件核实(#5451 route B)

核实结论:发布件有同构的 step 5 面 —— skills/objectstack-pm-dispatch/SKILL.md:377 ### 5. Dispatch,结构与内部件一致(派发令模板 + #### Dispatch backends 子节)⇒ 按 route B 加泛化版,插在派发令模板之后、#### Dispatch backends 之前。

泛化写法(实测约束,非假设):

发布件只写机制:「a semantic rule implemented more than once by compilers or evaluators that share no code ⇒ the prompt carries an explicit inventory of every implementing surface, and the agent gives a verdict for each one」,外加两条同样通用的纪律(inventory 由 PR 维护 / 粘贴前重新核对)与冻结面仍需申报。

6. 门禁 EXIT 表(git add 之后跑)

⚠️ 偏差记录:派发令里点名的 pnpm check:skill-docs 在本仓不存在。 实测 package.json 无该 script;.github/workflows/lint.yml 里也没有。已按 os-dev 规程从 lint.yml 逐个列门,补跑了发布件相关的真实门禁:check:published-files、check:skill-compatibility、check:quick-reference-counts、check:docs-audit-scope、check:adr-anchors(见表)。

7. Changeset

无 —— 纯文档、不发布任何包(.claude/** 不进任何包;skills/** 非 npm 发布物)⇒ 路线 2,PR 创建后立即加 skip-changeset 标签。

8. ⛔ 不在本 PR 里

• ⛔ lowering-layer 收敛调查 —— 维护者已裁 pm:on-hold,重启条件记在 [finding] 仓内存在 5 个独立的过滤器→谓词编译器,每次语义裁决成本 ×5 —— 值得立「谓词编译收敛」调查程序(#5298 成本清单副产品) #5930。本 PR 只做流程半边。
• ⛔ 不改任何编译器 / 求值器代码 —— 上表 5 面 + 半面一行代码都没动,本 PR 只是把它们写进清单。
• ⛔ 不搭 [skill] pm-dispatch:spec 车道 08-05/06 任期沉淀的 7 条 SKILL 更新建议(34 单 MERGED / 0 返工 / 一次交接全程即兴) #5925 的车 —— 它是别座位的单,状态未动。
• ⛔ 未触碰三轴决策框架(第 4 节三重取证)。
• ⛔ 未动 .claude/agents/os-dev.md、其他 skill、content/docs/releases/**、packages/**。

Generated by Claude Code